For commercial applications, a client computing platform typically operates in an environment where its behaviour is vulnerable to modification by local or remote entities. This potential insecurity of the platform is a limitation on its use by local parties who might otherwise be willing to use the platform, or remote parties who might otherwise communicate with the platform; for example, for the purposes of E-commerce.
The co-pending, commonly assigned application WO/48063, incorporated herein by reference, discloses a ‘trusted computing platform’ comprising a computing platform having a ‘trusted component’ including a built-in hardware and software component. This document describes the use of a Trusted Device (TD) or Trusted Platform Module (TPM) to enable verification of the integrity of computing apparatus by reliable measurement and reporting of integrity metrics. A TD/TPM conforms to the Trusted Computing Platform Alliance (TCPA) specification, see for example www.trustedpc.org.
A Trusted Device or Trusted Platform Module typically includes one or more logically protected computing environments or “compartments” within which a service or process can be run. The actions or privileges within a compartment are constrained, particularly to restrict the ability of a process to execute methods and operations which have effect outside the compartment, such as methods that request network access or access to files outside of the compartment. Also, operation of a process or service within a compartment is performed with a high level of isolation from interference and prying by outside influences. The or each compartment can be an operating system compartment controlled by an operating system kernel. This arrangement is referred to as a compartmented operating system or a trusted operating system.
Trusted operating systems have been available for several years in a form designed for handling and processing classified (military) information, using a containment mechanism enforced by a kernel of the operating system with mandatory access controls to resources of the computing platform such as files, processes and network connections. The operating system attaches labels to the resources and enforces a security policy which governs the allowed interaction between these resources based on their label values. Many trusted operating systems apply a security policy based on the Bell-Lapadula model discussed in the paper “Applying Military Grade Security to the Internet” by C I Dalton and J F Griffin published in Computer Networks and ISDN Systems 29 (1997) 1799-1808.
In any event, many trusted computing platforms adopt a relatively simple and convenient form of operating system compartment. As a general rule, each resource of the computing platform which is to be protected is given a label indicating the compartment to which that resource belongs. Mandatory access controls, incorporating a security policy, are performed by the kernel of the host operating system to ensure that resources from one compartment cannot interfere with resources from another compartment.
The above-mentioned security policy tends to be expressed in the form of security rules (each generally comprising an instruction line). In general, one or more security rules are associated with a compartment, and each compartment is associated with one or more services.
In the past, it has been considered desirable to load the security rules as early in the startup sequence of a platform as possible, so relevant security rules are in force as soon as a service or process is started. As such, in prior art systems, all security rules tend to be loaded to the platform at the time of system initialisation, i.e. a complete security policy is loaded at system startup.
However, this is not necessarily efficient, convenient or practical for a number of reasons. Firstly, some networking security rules use hostnames instead of numerical IP addresses, and hostname resolution does not tend to be available at startup, i.e. prior to the commencement of networking, so there is frequently not any available facility for looking up specified hostnames and translating them into the respective numerical IP addresses, such that there is no facility for recognising host names at that stage.
Further, some security rules refer to service ports which are allocated dynamically, i.e. a specific port may be allocated to a different service each time the system is initialised and/or a specific service may be allocated to a different port each time the system is initialised. In many cases, the port being used by a specific service will not be known until that service starts, i.e. after the startup process has been completed.
Still further, and notwithstanding the problems referred to above, most security rules relate to specific services, such that if the entire security policy is loaded at system startup, there will be a significant number of security rules loaded which relate to services that are not enabled. This is clearly an inefficient use of both processing power and memory capacity of the system.